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REMARKS 



Claims 1-13, 15-18, and 21-28 are pending. In an Official Action dated November 23, 
2007, claims 1, 2, 7-9, and 24-26 were rejected under 35 U.S.C. § 102, and claims 3-6, 10-13, 
15-18, 21-23, and 27-28 were rejected under 35 U.S.C. § 103. The rejections are respectfully 
traversed. 

Interview Summary 

Applicants thank the Examiner for the courtesy of a telephonic interview on January 
14, 2008. At the interview, the Examiner agreed to withdraw the outstanding rejections, and 
conduct a further search as necessary to determine if any further rejection under 35 U.S.C. §§ 
102 or 103 will be made. 

Rejections Under 35 U.S.C. § 102 

Claims 1, 2, 7-9, and 24-26 were rejected under 35 U.S.C. § 102(b) as allegedly 
anticipated by RFC 3244 Microsoft Windows 2000 Kerberos Change Password and Set 
Password Protocols by Swift et al. (hereinafter Swift). Applicants respectfully traverse. 

Applicants note that these rejections are the same as made previously, in an Official 
Action dated July 17, 2007, and traversed in a response filed October 17, 2007. Applicants 
traverse the rejections for the same reasons explained in the previous response. The following 
remarks address inaccuracies in the Official Action that, when correctly understood, 
necessitate withdrawal of the rejections. 

First, the Official Action suggests Swift discloses changing of "change password" 
protocols (which is incorrect because Swift does not disclose this, as discussed below), and 
that by specifying a particular protocol, a client would implicitly specify an encryption 
algorithm that goes along with the protocol. As stated in the "Response to Arguments" 
section on page 2 of the Official Action: 
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Swifts .discloses the dvangbg of password protocols see Page3 last sentence bridging onto 
Page 4. Arid fttrth^r "discloses that, the appropriate key types bdng generated from the 
password, aae Page 3 Par- 2- And this keytypes k bmng used to encrypt a packet, thus by 
extension cha^gbg; of password protocol -implicitly dwigss tiie encryption algorithms(ie* 
kef types fading vdianged). And additionally, Swift man! on s eiK^subtian (no 'enc^rakti on) 
which k .associated with the torsion of protocol see Page 3 Far* 4 "The server,*.* 1 

However, Swift never states that different encryption algorithms are used in different 
"change password" protocols. Therefore, it cannot be implied that Swift would change from 
one encryption algorithm to another. That is, the Official Action overlooks the possibility that 
a same encryption algorithm can be assumed for more than one protocol. 

Secondly, Swift does not disclose "changing of pas sword protocols" as suggested in 
the above text of the Official Action, but rather discloses a "change password" protocol. That 
is, Swift discloses a protocol for changing a password, not switching between two different 
protocols for changing a password. Thus, even if the Official Action were correct in saying 
that changing of protocols would imply changing of encryption algorithms, the rejection 
would still be improper, because Swift in fact does not teach "receiving an encryption 
algorithm negotiation request" by virtue of protocol negotiation. Swift does not teach 
protocol negotiation. 

For these reasons, independent claims 1, 8, 15, and 24 each contain at least one 
limitation that is not taught or suggested by RFC 3244. The at least one limitation in 
independent claims 1, 8, and 24 that is not found in RFC 3244 is the "encryption algorithm 
negotiation request" recited in claims 1 and 8 and the "negotiation request" of claims 15 and 
24. Claims 2, 7, 9, 25 and 26 depend directly or indirectly from claims 1, 8, and 24 and 
therefore also define over RFC 3244. 

Rejection Under 35 U.S.C. § 103 

Claims 3-6, 10-13, 15-23, and 27-28 were rejected under 35 U.S.C. § 103(a) as 
allegedly unpatentable over Swift in view of rpcsec_gss, kadmin service principal (Coffman). 
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While the Official Action admits that RFC 3244 does not disclose all the elements of claims 
3-6, 10-13, 15-23, and 27-28, it is alleged that Coffman cures this deficiency. The rejections 
are respectfully traversed for the reasons provided above. 

Claims 3-6, 10-13, 16-18, 21-23, and 27-28 depend directly or indirectly from claims 
1, 8, 15, and 24. Claim 15 is independent and contains the "negotiation request" element 
discussed above. Coffman does not teach, and the Official Action does not allege that 
Coffman teaches, an "encryption algorithm negotiation request" or "negotiation request." 
Like Swift, Coffman is devoid of any reference to an encryption algorithm of any kind. 
Therefore Coffman does not cure the deficiency of Swift. 

Reconsideration and withdrawal of the outstanding rejections is respectfully 
requested. 



Date: January 23, 2007 /Nathaniel Gilder/ 
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